Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

chrome - use tab's current host rather than 127.0.0.1 #16

Open
wants to merge 2 commits into
base: master
Choose a base branch
from

Conversation

jgallen23
Copy link

fixes #15

@doughsay
Copy link

Please merge this and re-publish to chrome store. This plugin is awesome, but completely useless if your development box is not localhost.

@jtomaszewski
Copy link

Seems like there's no support from the author ;/ Shall we publish it on Chrome Apps ourselves? The lack of this option kills me in almost every project I work on.

The source seems to be MIT licensed .

@kolya-ay
Copy link

It seems that @bigwave has the most uptodated version. However the firefox extension seems to have the similar bug..

@bigwave
Copy link

bigwave commented Jan 25, 2014

I've published this to the Chrome App Store, but you need the URL to install it.

https://chrome.google.com/webstore/detail/remotelivereload/jlppknnillhjgiengoigajegdpieppei

It's only available if you know the URL because this is my first published extension, and it's still a bit rough. No description, screenshots, etc. etc.

Feedback appreciated.

@bigwave
Copy link

bigwave commented Jan 25, 2014

Could you try this and see if it works?

https://addons.mozilla.org/en-US/firefox/addon/remotelivereload/

@kolya-ay
Copy link

kolya-ay commented Feb 6, 2014

Ohh.. I have missed your comment somehow. Yes, now it works as expected.

I have also forked the repo and replaced extension's building system to Grunt. Now it builds with npm install && grunt which (I hope) is much cleaner and looks more native to JS-projects (no need to rake). It supports also project's parametrs substitution (i.e no need to handcode version, author, etc in different files) which is good for futher build automation.

Would you like to merge this to your fork? Should I PR to you?

@bigwave
Copy link

bigwave commented Feb 6, 2014

Yes please, I only learnt rake for this project, so I'm happy to have something JavaScript based

@kolya-ay
Copy link

kolya-ay commented Feb 7, 2014

Ok. So I think you should git remote add my fork, get the changes and start playing with version increasing in package.json

@bigwave
Copy link

bigwave commented Feb 9, 2014

Merged, version incremented and re-published for Chrome and Firefox (just to make sure the new build process works for deploys to apps stores)

@pcorey
Copy link

pcorey commented Nov 5, 2014

Thanks for this guys! It's a shame this pull hasn't been accepted yet...

@andreyvit
Copy link
Member

Hey! Sorry guys for neglecting this for so long; I'm back to active maintenance.

That said, I'm afraid I don't agree with this feature as is. A valid use case for LiveReload is to run it on a live web site (say http://livereload.com) with a local server serving CSS overrides.

What's your use case for it? Running grunt-watch on a remote system?

@andreyvit
Copy link
Member

@kolya-ay @bigwave @jtomaszewski If you guys are interested, I can give commit access to the main repo to anyone who wants to contribute in general.

Regarding this particular change, I'd love to resolve it without introducing options or other complications like that. How about trying localhost first, and then, if it doesn't respond, trying the page's origin domain?

@jk-
Copy link

jk- commented Jan 20, 2015

@andreyvit in our case the grunt-contrib-watch is being ran on a virtual machine so localhost/127xxx wont work.

@bigwave
Copy link

bigwave commented Jan 20, 2015

@andreyvit My personal use case is playing about with web sites on a raspberry pi to control servos, LEDs, cameras, etc. And I don't want to run a "non-standard" browser on low power hardware, so I use ssh and browsers on my laptop.

Probably not the most common use case I will admit.

@kolya-ay
Copy link

@andreyvit, my use case is opposite to @js-'s. I run grunt watch on my linux workstation and watch the result in virtualbox machine which contains my browsers zoo. I suppose this is quite common workflow for Linux/MacOS users.

How about trying localhost first, and then, if it doesn't respond, trying the page's origin domain?

The solution looks reasonable: localhost first because of virtual opportunity to have two (local & origin) livereload servers started. However it's still hard to imagine who wants to modify locally the beautiful http://livereload.com CSS;)

Regarding the project future, could you take a look on commits I have made a year ago. Besides relayout the fork contains some useful grunt automation (version inferring, crx building). Would you consider a PR from me?

@andreyvit
Copy link
Member

@kolya-ay I've already did some relayout (including a switch to Grunt for builds), check it out. I'll happily merge most of pull requests, unless I particularly disagree with something.

You have a lot of useful changes in there, like a keys directory. I'm not sure I want to switch all extensions to a template copying approach; I thought about it, but at least the Safari extension's manifest needs to be edited in Safari GUI, so a separate copy would be harder to maintain.

I've kept version stuff in Rake for now, because I hate editing Gruntfiles (can't wait till I build some GUI for that, been on my mind forever), but I'm open to switching to Grunt for that as well.

@kolya-ay
Copy link

Ok, it's matter of taste;) Should I make a PR to include origin listening?

By the way, I'm not sure, but it seems that building the Safari extension could be automated too.

@andreyvit
Copy link
Member

@kolya-ay Well I can do it myself, but if you have time next week or two, you'll beat me to it.

Given that the script reconnects on each reload, I think it's best to start connecting to both endpoints at the same time. And if both succeed... well why not stay connected to both? But if that's too much work, I guess we can just pick the first one to connect.

@camilonova
Copy link

@andreyvit can you please merge it?

@ikks
Copy link

ikks commented Apr 9, 2015

@andreyvit the use case here is having a docker instance for developing, so it's really useful. Please merge it

@andreyvit
Copy link
Member

@camilonova, @ikks I understand the use case, but this change breaks the normal usage with my app, so it cannot possibly be merged as is.

@camilonova
Copy link

@andreyvit you already have a workaround at http://feedback.livereload.com/knowledgebase/articles/86180-how-do-i-add-the-script-tag-manually

Seems it will keep the normal use of the app, but it will not work for anyone running the dev server different than localhost.

Why do you think it break your normal usage?

@camilonova
Copy link

@andreyvit could you at least merge #35 which seems to change a lot less than this one?

@mpdude
Copy link

mpdude commented Jun 10, 2015

chime in

What about the idea of trying 127.0.0.1 first (for BC) and then resorting to the tab's host?

For me, everything (including the watch & livereload) runs inside a Vagrant virtual machine, so 127.0.0.1 does not work.

@lokcito
Copy link

lokcito commented Nov 7, 2018

Seems like there's no support from the author ;/ Shall we publish it on Chrome Apps ourselves? The lack of this option kills me in almost every project I work on.

The source seems to be MIT licensed .

I have just upload a custom version that allow set your custom host and port:
Here the link: https://github.com/lokcito/livereload-extensions
Download here: https://github.com/lokcito/livereload-extensions/raw/master/dist/2.1.0/LiveReload-2.1.0-ChromeWebStore.zip

@Elephant-Vessel
Copy link

It would be nice if this could be fixed for us that have VMs as dev-machines.

@heidyosores
Copy link

It would be nice if this could be fixed for us that have VMs as dev-machines.

Here the link where you can define the host: https://github.com/lokcito/livereload-extensions
Download here: https://github.com/lokcito/livereload-extensions/raw/master/dist/2.1.0/LiveReload-2.1.0-ChromeWebStore.zip

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Chrome: Use current domain as host